1. Technical Field
This disclosure relates generally to web application security and in particular to a method and system for detecting and applying different security policies to active client requests.
2. Background of the Related Art
Traditional secure web servers have deficiencies in servicing active client code requests originating within authenticated (user) browser sessions. As is well-known, “active client” code refers to software (typically code executing within a web browser) that runs without user intervention or control. Active client code typically is Asynchronous JavaScript and XML, collectively referred to as AJAX. While active client code can provide useful functionality, it can also create undesirable behaviors within browsers, especially with respect to user-centric security policy controls (e.g., inactivity time-outs), as well as during dynamic response rendering.
In particular, web server user session inactivity time-outs are designed to provide some protection against unauthorized use of a secure web session. Typically, inactivity time-outs are statically configured by the secure web server using configuration data. Such time-outs may also be set dynamically on a per user/session basis. If the client system becomes idle for the configured period of time, theoretically the server that holds the session marks the session as unusable until such time as either (a) never, or (b) the user authenticates again. When configured for re-authentication, the user is prompted for authentication credentials, the receipt of which un-locks the session to be used again. In many web applications, however, active code running within the browser often sends requests without direct input by the end user. In such cases, the secure web server responds to such requests by re-setting the inactivity countdown timer. As a result, even if the user walks away from his or her computer for an extended time period, the secure web server continues to honor these active client requests and, in so doing, it continually re-sets the inactivity countdown timer. This results in the inactivity time-out failing to satisfy the configured time-out period, resulting in a potential security exposure for end users.
One approach to addressing the problem of active code overriding the inactivity time-out is to specify a fixed set of URLs to be excluded from impacting the inactivity countdown timer. This approach, however, requires an administrator of the system to know all of the URLs (or at least portions thereof) so that they can be configured into the system. This is not always practical, as many web developers are not aware of the resulting request access URLs. Another approach to this problem involves deploying alternative web server gateways to service the active code requests. This requires additional hardware, and therefore additional cost. In addition, in the event these AJAX requests require authentication, it is necessary to embed cryptographic tokens in each web service request, which is non-optimal from a performance or cost perspective.
Another problem involves the issue of how the web server process should respond to the active client request. In dynamic response rendering, once a request is detected, the response from the web application should be inspected to ensure that the response content is appropriate for the active client code. In current secure web servers, if an error is detected, often the active client code is delivered a generic response that the client does not expect, or should not expect, to handle. In the case of a secure session, if the user's session expires, the user would then be prompted to authenticate again using a web form. In most cases, such a response is not handled suitably by active client code. While AJAX code could be developed to handle an unexpected response from the server within the active code itself, this is not optimal, as every AJAX-style request would need to have associated response code handling. This is not achievable in a typical secure web server-based operating environment, especially where reverse proxies are deployed across many web applications.
Having the ability to detect and act upon active client requests in a different way to normal browser requests would help to alleviate these deficiencies, especially in the active client scenarios described.